I am not in favour of the name DefaultDepthSetter. This is very specific to the intended use-case but it should be a versatile interface to be used by other components as well. As you describe the interface as "depth-lookup" why not calling it DepthLookup or DepthQuery or DepthProvider?. I would appreciate if we could discuss such ideas and names prior to a PR to avoid discussions and additional work later on for you as well.

I am not in favour of the name DefaultDepthSetter. This is very specific to the intended use-case but it should be a versatile interface to be used by other components as well. As you describe the interface as "depth-lookup" why not calling it DepthLookup or DepthQuery or DepthProvider?. I would appreciate if we could discuss such ideas and names prior to a PR to avoid discussions and additional work later on for you as well.

Yeah you are right. Which one you prefer me to go with?
DepthLookup looks good to me?

Just thinking, if we already have a class doing a similar thing ... Regions comes into my mind, so not very helpful ;)
Yes, DepthLookup sounds reasonable. At least not Setter because it does not set anything, it just replies to a query.

Addressed Jan's review feedback:

• Class name: renamed DefaultDepthSetter → DepthLookup (done in previous commit)
• Copyright / code style: old defaultdepthsetter.* files replaced entirely
• Config namespace: backends use depths.<backend>.* (done in previous commit)
• Throw-based API (main change in this update): fetch() and fetchMaxDepth() now throw std::out_of_range when no region/zone contains the given location. Two utility free functions fetchDepth() and fetchMaxDepth() are provided for callers that need a fallback value. DepthLookupPolygon no longer owns a fallback or reads depths.polygon.fallback.

Do we have the possibility to retrieve more than one depth? I am referring to the situation where there is deep seismicity along a subducting slab, but also shallow seismicity right above it. That separation can be significant and we need to be careful not to trust a potentially wrong depth.

Thank you for the changes. What I still do not like very much are the utility functions. I proposed that initially to provide a fallback rather than incorporating it into the fetch methods. The better design worked out later was that the client (scautoloc) does not need to provide a default depth. This is currently required as the methods throw exceptions and someone needs to deal with that and provide a fallback. Where does that fallback come from? I prefer that knowledge to be completely encapsulated in the DepthLookup backend and not in the client.

Do we have the possibility to retrieve more than one depth? I am referring to the situation where there is deep seismicity along a subducting slab, but also shallow seismicity right above it. That separation can be significant and we need to be careful not to trust a potentially wrong depth.

Good point , the current interface only returns a single depth. Are you thinking the interface should return a list of candidate depths for scautoloc to try, or more that scautoloc itself should decide to try both a shallow and a slab-based seed independently?

Thank you for the changes. What I still do not like very much are the utility functions. I proposed that initially to provide a fallback rather than incorporating it into the fetch methods. The better design worked out later was that the client (scautoloc) does not need to provide a default depth. This is currently required as the methods throw exceptions and someone needs to deal with that and provide a fallback. Where does that fallback come from? I prefer that knowledge to be completely encapsulated in the DepthLookup backend and not in the client.

Understood, fetch() should always return a value, with the fallback knowledge fully encapsulated in the backend. The client should never need to handle an exception or supply a depth. Will remove the utility functions and have each backend return its own configured fallback when no zone matches.

Why do I have the feeling chatting with Claude AI rather than yourself? ;)

Thank you for the changes. What I still do not like very much are the utility functions. I proposed that initially to provide a fallback rather than incorporating it into the fetch methods. The better design worked out later was that the client (scautoloc) does not need to provide a default depth. This is currently required as the methods throw exceptions and someone needs to deal with that and provide a fallback. Where does that fallback come from? I prefer that knowledge to be completely encapsulated in the DepthLookup backend and not in the client.

Done, removed the utility functions and the fallback is back where it belongs, inside the backend. fetch() and fetchMaxDepth() always return a value now, the client doesn't know or care about fallbacks.